home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / misc-part1 / 706 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.8 KB

  1. Path: news.mpd.tandem.com!usenet
  2. From: Joseph Crowe <jcrowe>
  3. Newsgroups: comp.sys.amiga.misc
  4. Subject: Re: OS features
  5. Date: 8 Jan 1996 22:07:46 GMT
  6. Organization: Tandem Computers,Inc. (Austin, TX)
  7. Message-ID: <4cs4ji$rou@news.mpd.tandem.com>
  8. References: <92747544038@PAPA.NORTH.DE> <4b3h9s$1st@alterdial.UU.NET> <2152.6561T63T2136@cycor.ca> <4b7i18$si1@vixen.cso.uiuc.edu> <oj6raxxrr0o.fsf@hpsrk.fc.hp.com> <13213431@sourcery.han.de> <4cp0un$cve@serpens.rhein.de>
  9. NNTP-Posting-Host: argyle
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 1.1N (X11; I; IRIX 5.3 IP22)
  14. X-URL: news:4cp0un$cve@serpens.rhein.de
  15.  
  16. Hi Michael,
  17. mlelstv@serpens.rhein.de (Michael van Elst) wrote:
  18. >Protection is usually an asymmetric task. A (user)task must not corrupt data
  19. >structures used by other (user)tasks but a system library that manages
  20. >shared objects may corrupt data structures in (user)tasks. Reason is
  21. >that a shared library can be debugged more easily.
  22.  
  23.    I'm struggling to understand what you mean by the above paragraph.  I don't
  24. find it at all desirable to have a system where an interface library can
  25. arbitrarily corrupt data structures in user task space.  Could you relate this
  26. concept to a more concrete example?
  27.  
  28. >
  29. >For interprocess communication one has to provide a new protected method.
  30. >Messages of non-trusted tasks may have to checked for consistency.
  31. >Again, for most applications we have one "server" that is shared among
  32. >several clients. The server can be made for error proof and thus is
  33. >allowed to corrupt client data. But the client must not corrupt server
  34. >data or the data of other clients.
  35.  
  36.    Are you saying that some sort of object server should be allowed to
  37. arbitrarily corrupt an instantiation of a client or even an inherited object in
  38. the client tasks memory area?  Not in any OS I'd ever own.
  39. >
  40. >Anyway, before you can think about memory protection you have to solve
  41. >resource tracking. There are some difficulties involved, mainly in
  42. >arbitration of shared objects (or rather the lack of arbitration).
  43.  
  44.    True....the UNIX method of solving this problem works OK, even if it is sort
  45. of ugly and not too elegant.  Essentially, security is provided by the standard
  46. UNIX ownership mode bits.  For shared memory, give some range that is set up by
  47. a task with a shared memory ID, there is the concept of owner, group and others
  48. and permissions to read and/or write.  Once it is set up, the owner task can
  49. even exit while the shared memory segment remains.  Other tasks, if they have
  50. the correct permissions, may attach the shared memory and it then gets mapped
  51. into their address range.  Other IPCs work in a similar manner.  To implement
  52. something similar in an OO environment should not be too difficult.  It would
  53. still allow memory protection for task/process addressability and even would
  54. result in a SIGSEGV(in UNIX speak), if a task attempted to write outside the
  55. range of the shared memory it had attached.  
  56. >
  57. >>   That's an idea. I have seen similar under BeOS which can put contiguous
  58. >>memory regions together from fragments.
  59. >
  60. >With virtual memory the fragmentation exists in the virtual address
  61. >space. The effect of this fragmentation is small because the virtual
  62. >address space is much larger and because virtual addresses are allocated
  63. >with a rather coarse granularity. Fragmentation smaller than the page
  64. >size just affects one task and is effectively removed when the task
  65. >ends.
  66.  
  67.    With demand paged VM, there's often multiple sizes of allocation units, at
  68. least, once you leave user space.  Even with the limitation of a single size of
  69. page, it amounts to a win because pages of data, instructions, stack, buffer
  70. cache etc., will only exist in physical memory when needed and will only stick
  71. for as long as they are frequently accessed, depending on the page-aging
  72. algorithm.  Most shared library implementations in UNIXland will not even bring
  73. in a single page of a shared library until a page fault occurs attempting to
  74. access and instruction from that library.  Same goes for any other instructions
  75. on the user side of the system call interface.  It's not perfect, or people
  76. like me would not be employed....;^)....but it's fairly effective when compared
  77. with a non-protected environment.  
  78. >Separated address spaces for each process are even better because
  79. >the total address space now grows with the number of processes. But
  80. >this approach costs a lot in compatibility. It might be possible
  81. >to use partially separated adress spaces though in new programs.
  82.  
  83.    Maybe for data, but please do not blow off re-entrant shared code.  
  84. >
  85. >Regards,
  86. >-- 
  87. >                                Michael van Elst
  88. >
  89. >Internet: mlelstv@serpens.rhein.de
  90. >                                "A potential Snark may lurk in every tree."
  91.  
  92. -- 
  93. Joseph Crowe
  94. jcrowe@isd.tandem.com
  95.  
  96.